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REMARKS 

Claims 1-47 stand rejected as anticipated by Brandt et al. (US 6,714,979). The 
Applicants respectfully traverse these rejections. 

According to exemplary embodiments of the present invention, an improved 
method for accessing and managing data stored on a mainframe database system is 
provided. As described, e.g., at page 2 of the application, in the past, that data was 
obtained from the mainframe database system by printing reports to a paper printer. The 
person requesting those printed documents was required to collect and assemble the 
printed documents, and then filed those documents in a file cabinet after obtaining the 
desired information. Some so-called legacy mainframe database systems were operated 
to provide printed reports of selected information stored on those systems, but were not 
considered readily adaptable to a relatively paper-free environment where printed reports 
are eliminated or significantly reduced in number and content, and where individual users 
can easily obtain desired information in various formats. 

The foregoing and other problems are overcome, according to exemplary 
embodiments, with a method in which reports for customer requests are generated based 
on the customer data received in a mainframe database system. Summaries of those 
reports are provided to a printer emulator, instead of going to a printer as in the prior art. 
Selected data from those report summaries next are imported into a spreadsheet, which in 
turn is provided to at least one terminal where the spreadsheet contents are available as 
needed. As the specification points out, the "at least one terminal" to which this 
spreadsheet is provided are, in an exemplary embodiment, one or more PCs accessing the 
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spreadsheet information from a file server available through a local area network or the 
Internet. 

According to exemplary embodiments, the mainframe database system "sees" a 
conventional printer when, in fact, it is supplying the generated reports to the printer 
emulator. Reports thus are generated from customer data received on the mainframe 
database system without printing, handling, or storing actual printed reports as in the 
prior art. Selected data is then imported from the report summaries into a spreadsheet, 
where that selected data is provided to at least one terminal. 

Claim 1, for example, recites a method for managing customer service request 
reports. The method comprises receiving customer data in a mainframe database system, 
generating a report for each of a plurality of customer requests based on the customer 
data in the mainframe database system, providing summaries of the reports to a printer 
emulator, importing selected data from the report summaries into a spreadsheet, and 
providing the spreadsheet to at least one terminal. 

Brandt fails to disclose the step of providing report summaries to a printer 
emulator. The reference thus fails to anticipate the method of Claim 1. Moreover, that 
reference does not address or solve the problems confronted by the present Applicants, as 
discussed above. 

The rejection contends that Brandt "[provides] summaries of the reports to a 
printer emulator, as a customer list", citing column 3, line 65 through column 4, line 12 
of the reference. However, no mention of a printer emulator appears in the cited text. 
Instead, that passage discusses a system for allowing predetermined telephone customers 
to extract and receive call data. From the cited passage as well as the greater context of 
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the disclosure in Brandt, that reference discloses what looks like a ground-up design 
intended to replace data delivery systems, shown in Fig. 1 of Brandt and there designated 
"Prior Art", using legacy mainframe systems capable only of providing customers with 
periodic canned reports (column 3, lines 6-18 of Brandt). Brandt goes on to describe a 
system designed to avoid those prior-art problems, and Brandt's system thus has no need 
for generating reports based on customer data in a mainframe database system and 
providing summaries of those reports to a printer emulator. Brandt fails to disclose that 
step and, accordingly, fails to anticipate the Applicants' Claims 1 et al. 

Claims 2-7 depend directly or indirectly from Claim 1 and thus are novel over 
Brandt for the reasons discussed above. 

Independent Claim 8 likewise defines a method including, among the other 
recited steps, providing summaries of reports, generated on a mainframe database system, 
to a printer emulator. Claim 8 thus defines an overall combination of method steps not 
anticipated by Brandt. 

Claims 9-17 depend from Claim 8, directly or indirectly, and likewise are novel 
over Brandt. Moreover, Claims 13-15 require that each report generated on the 
mainframe database system include a unique report number, with that report number 
comprising a file name for each saved printed report per Claim 15. The rejection of 
Claim 13 contends that Brandt, specifically column 10, lines 46-49, includes a unique 
report number associated with each report. However, that cited passage merely states 
that a customer request submitted via an SSL connection is tagged with a unique 
identifier, after which the socket connection is closed. The client 50 then polls the 
application server 60 on a periodic basis until a response is ready, each poll occurring on 


4 



S/N 09/995,042 


a new socket connection to the proxy. The "unique identifier" mentioned at line 48 in 
column 10 of Brandt thus identifies a customer request to the proxy, not a report (printed 
or otherwise) based on that request. Further, that "unique identifier" is used only to 
identify the request each time a poll occurs on a new socket connection to the proxy. 

Once the proxy responds with the resultant data, that "unique identifier" is not further 
mentioned and, presumably, vanishes as no longer needed. Accordingly, Brandt fails to 
disclose including a unique report number associated with each report, and Claims 13-15 
are novel for that additional reason. 

Dependent Claims 16 and 17 recite the further steps of connecting to the 
mainframe database base system with a terminal emulator, and wherein a single computer 
comprises the printer emulator and the terminal emulator. The rejection asserts that Web 
browser 50 of Brandt comprises the printer emulator and the terminal emulator, 
supposedly as disclosed at column 28, line 44 and at column 29, line 11. However, those 
portions of columns 28 and 29 only discuss the report viewer 215, and an applet 
providing a graphic user interface to analyze and display the data and reports supplied 
from the servers 400, 500, and the like. Please see column 28, lines 24-28. Nothing 
therein is seen to anticipate providing a terminal emulator connected to the mainframe 
database system, either separately from or combined with the printer emulator. 

The method of Claim 18 also requires connecting to the mainframe database 
system with a terminal emulator. Moreover, the method of Claim 18 includes the step of 
assigning a unique report number for each generated report. As pointed out above, 

Brandt fails to disclose at least those steps, and that reference thus does not anticipate the 
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overall method of Claim 18. Dependent Claims 19-24 likewise are novel over that 
reference. 

Dependent Claim 22 adds the further step of deleting the customer data from the 
mainframe database system. Claim 23 depends from Claim 22 and adds the step of 
deleting the generated reports from the mainframe database system, and dependent Claim 
24 recites that each generated report is deleted after that report is selected and provided to 
the terminal emulator. The rejection contends that column 36, lines 20-22 of Brandt 
teach the steps added by Claims 22, 23, and 24. However, that passage mentions only a 
request to delete "a user-created report from the user table" (italics added), which is not 
deleting the customer data from the mainframe database system as defined in the overall 
method of Claims 22-24. Brandt discusses user-created reports at column 35, lines 26- 
42, and elsewhere, with those reports being created from data stored on the equivalent of 
a mainframe. Nothing in Brandt discloses deleting customer data from the mainframe. 

Independent Claim 25 defines a system for managing certain reports. That system 
includes a mainframe database system, and a computer comprising a printer emulator and 
a terminal emulator in communication with the mainframe database system, among other 
elements in the recited combination. As previously pointed out, Brandt does not disclose 
a system including a printer emulator or a terminal emulator in connection with the 
mainframe database system receiving customer data. Accordingly, that reference does 
not anticipate Claim 25 or Claims 26-32 dependent (directly or indirectly) thereon. 

Method Claim 18 recites, among other steps, generating a report from customer 
data on a mainframe database system, assigning a unique report number for reach 
generated report, generating a file comprising report numbers for the selected reports, and 
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providing that file to a printer emulator. Brandt, as discussed above, fails to anticipate 
the steps of providing the file to a printer emulator, and of generating a file comprising 
report numbers for selected reports. Further, that reference does not anticipate the step of 
connecting to the mainframe database system with a terminal emulator, also as recited in 
Claim 33. Accordingly, Claim 33, together with dependent Claims 34 -41, are novel over 
Brandt. 

Moreover, Claims 39-41 recite the further step of deleting customer data from the 
mainframe database system. Brandt does not anticipate that further step, as pointed out 
above. Claims 39-41 are thus considered novel over Brandt for that further reason. 

Claim 42 defines a system including a mainframe database system for receiving 
customer data, and a computer comprising a printer emulator and a terminal emulator in 
connection with the mainframe database system, in combination with other recited 
elements. With this claim system, the mainframe database system generates reports for 
plural customer usage submissions, at least one generated report is selected for printing, a 
file is generated comprising report numbers associated with those selected reports, and 
the file is printed to the printer emulator. Taking those elements along with the overall 
structural and functional limitations set forth in Claim 42, Brandt fails to anticipate for 
the reasons set forth above. Accordingly, that claim and dependent Claims 43-47 are 
novel over Brandt. 


1 



S/N 09/995,042 


The foregoing is submitted as a complete response to the Office Action identified 
above. The Applicants respectfully submit that this case is in condition for allowance 


and solicit a notice to that effect. 


Date: June 23, 2004 


Merchant & Gould, LLC 
P.O. Box 2903 

Minneapolis, MN 55402-0903 
Telephone: 404.954.5100 


Respectfully submitted, 
MERCHANT & GOULD 
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